1. Field of the Invention
This invention relates to the field of telecommunications systems, and more particularly, to systems and methods for allocating telecommunication resources to an application in a telecommunications system.
2. Description of the Related Art
Conventional computer telephony products allow for connecting applications to particular computer telephony resources, or components. To connect these components within a computer telephony product, the application must be written to use each manufacturers programming interface for the application to be able to communicate with the telephony resources. For each telephony resource within a computer telephony product, it is necessary to write a portion of the application that is dedicated to issuing instructions to that particular type of telephony resource.
In conventional computer telephony products, each application includes a design phase, coding phase, testing phase, and integration phase. Specifically, each portion of the application must be designed to integrate with a specific functionality of each dedicated computer telephony resource and the overall product. This functionality is specifically coded, or written, using computer language code. Each coded portion of the application is then tested to ensure that it functions exactly as designed. Finally, each portion of the application must be integrated to create the final product.
In creating such conventional computer telephony products, multiple development paths are followed during the development cycle. Further, the complexity of conventional computer telephony products requires a large number of paths and a large number of operations along each path. Specifically, these paths must be followed for each portion of the overall system, such as an interface to a particular computer telephony resource or a particular user interface. Moreover, in every instance that a computer telephony resource is changed or added, the appropriate development paths must also be changed or added. This is particularly troublesome when the computer telephony resource involves different types of hardware.
To help ease development, a first generation of software based computer telephony products used Computer Aided Software Engineering (CASE) tools to design systems. These conventional CASE development systems make it easier to determine how many paths or what changes are needed on a given path to build or reconfigure a computer telephony product. These conventional systems, however, do not reduce complexity because they can not, for example, reduce the number of paths needed to complete changes in a conventional computer telephony product.
A second generation of software based computer telephony products used Code Generators (CG) to design systems. The CG development systems automated the process for developing paths to completion. This makes the actual time spent following the paths to completion more reasonable. Conventional CG developed or derived systems, however, have numerous drawbacks. For example, similar to the conventional CASE developed systems the CG developed systems cannot reduce the number of paths necessary to be followed for completion.
Moreover, any additional computer code input beyond that generated by the CG program is lost and must to be re-done for each change in the path to completion. These changes, of course, are tedious and laborious and the process is prone to introducing new or additional errors into the computer telephony product.
To further help ease the development process, a third generation of computer telephony products developed through the vendor companies that produce the computer telephony resources. Specifically, these vendors developed two divergent design schemes that provide design specifications that computer telephony resource manufactures might follow. If followed, the specifications allow for computer telephony resources from different vendors to operate within the same computer telephony product.
The first of the two design schemes developed is Multi-Vendor Interface Protocol (“MVIP”) and the second design scheme is SCBus. It is noted that the original design scheme was called SCSA for Signal Computing System Architecture, later this was modified to SCBus, which is Signal Computing Bus, and it has now been extended for multi-chassis integration and is call SCX Bus for Signal Computing extended Bus.
Although these design schemes allow for having multi-vendor computer telephony resources within a single conventional computer telephony product, there are still drawbacks to this generation of computer telephony products. Foremost among the problems is that these standards only apply to the communications between telephony resources and make no changes in the application to telephony resource communication. That is, with the MVIP or SCBus protocol, it is possible to put different vendor's hardware into the same product, but the application must still be written to each individual telephony resource within the product.
In an attempt to address the shortcomings of the previous three generations, a fourth generation of computer telephony products was developed. These conventional computer telephony products were developed using the MVIP and SCBus design schemes and layered on a new application protocol that allowed multiple applications to run on a given set of computer telephony resources.
These conventional computer telephony products do allow for allocating multiple computer telephony resources among multiple applications, but only in a static manner. That is, resource allocation in these products is fixed during an initialization of the product by using a configuration file provided by a product administrator and this configuration file cannot be changed without re-starting or re-initializing the product which, of course, requires all applications to be shut down.
This fourth generation of computer telephony products still has a number of drawbacks. For example, the computer telephony resources must be allocated to an application before any application goes into operation. Further, these products lack flexibility, such as dynamic configuration, because all resources must be allocated at initialization to particular applications. Moreover, these products lack dynamic scalability because the addition or subtraction of new computer telephony resources requires re-start and re-initializing of the computer telephony product.
Therefore, there is a need for a telecommunication system and method that (1) allows for dynamic configurability of telecommunication resources that (2) does not require applications to be dedicated to particular telecommunication resources at development or system initialization, while (3) providing system flexibility and scalability by allowing for addition or subtraction of telecommunication resources without re-initializing the telecommunication services system and (4) provides fewer and shorter paths to completion for applications.